ജാവാസ്ക്രിപ്റ്റ് WeakRef ഒബ്സെർവർ പാറ്റേൺ: മെമ്മറി-അവയർ ഇവന്റ് സിസ്റ്റങ്ങൾ നിർമ്മിക്കാം

ആധുനിക വെബ് ഡെവലപ്‌മെന്റിന്റെ ലോകത്ത്, ഡൈനാമിക്, റെസ്‌പോൺസീവ് യൂസർ എക്സ്പീരിയൻസുകൾ സൃഷ്‌ടിക്കുന്നതിനുള്ള മാനദണ്ഡമായി സിംഗിൾ പേജ് ആപ്ലിക്കേഷനുകൾ (SPAs) മാറിയിരിക്കുന്നു. ഈ ആപ്ലിക്കേഷനുകൾ പലപ്പോഴും ദീർഘനേരം പ്രവർത്തിക്കുകയും സങ്കീർണ്ണമായ സ്റ്റേറ്റ് കൈകാര്യം ചെയ്യുകയും എണ്ണമറ്റ ഉപയോക്തൃ ഇടപെടലുകൾ നടത്തുകയും ചെയ്യുന്നു. എന്നിരുന്നാലും, ഈ ദീർഘായുസ്സിന് ഒരു മറഞ്ഞിരിക്കുന്ന വിലയുണ്ട്: മെമ്മറി ലീക്കുകളുടെ വർധിച്ച സാധ്യത. ഒരു ആപ്ലിക്കേഷന് ഇനി ആവശ്യമില്ലാത്ത മെമ്മറി നിലനിർത്തുമ്പോൾ ഉണ്ടാകുന്ന മെമ്മറി ലീക്ക്, കാലക്രമേണ പ്രകടനം കുറയ്ക്കുകയും, വേഗത കുറയുന്നതിനും ബ്രൗസർ ക്രാഷുകൾക്കും മോശം ഉപയോക്തൃ അനുഭവത്തിനും ഇടയാക്കുകയും ചെയ്യും. ഈ ലീക്കുകളുടെ ഏറ്റവും സാധാരണമായ ഉറവിടങ്ങളിലൊന്ന് ഒരു അടിസ്ഥാന ഡിസൈൻ പാറ്റേണിലാണ് സ്ഥിതിചെയ്യുന്നത്: ഒബ്സെർവർ പാറ്റേൺ.

ഇവന്റ്-ഡ്രിവൺ ആർക്കിടെക്ചറിന്റെ ഒരു ആണിക്കല്ലാണ് ഒബ്സെർവർ പാറ്റേൺ. ഇത് ഒബ്ജക്റ്റുകളെ (ഒബ്സെർവർമാർ) ഒരു കേന്ദ്ര ഒബ്ജക്റ്റിൽ (സബ്ജക്ട്) നിന്ന് അപ്ഡേറ്റുകൾ സബ്സ്ക്രൈബ് ചെയ്യാനും സ്വീകരിക്കാനും പ്രാപ്തമാക്കുന്നു. ഇത് ലളിതവും മനോഹരവും അവിശ്വസനീയമാംവിധം ഉപയോഗപ്രദവുമാണ്. എന്നാൽ അതിന്റെ ക്ലാസിക് നടപ്പാക്കലിന് ഒരു നിർണായകമായ പിഴവുണ്ട്: സബ്ജക്ട് അതിന്റെ ഒബ്സെർവർമാരുമായി ശക്തമായ റഫറൻസുകൾ നിലനിർത്തുന്നു. ആപ്ലിക്കേഷന്റെ മറ്റ് ഭാഗങ്ങൾക്ക് ഒരു ഒബ്സെർവറിനെ ഇനി ആവശ്യമില്ലെങ്കിൽ, എന്നാൽ ഡെവലപ്പർ അതിനെ സബ്ജക്റ്റിൽ നിന്ന് വ്യക്തമായി അൺസബ്സ്ക്രൈബ് ചെയ്യാൻ മറന്നാൽ, അത് ഒരിക്കലും ഗാർബേജ് കളക്ട് ചെയ്യപ്പെടുകയില്ല. ഇത് മെമ്മറിയിൽ കുടുങ്ങിക്കിടക്കും, നിങ്ങളുടെ ആപ്ലിക്കേഷന്റെ പ്രകടനത്തെ വേട്ടയാടുന്ന ഒരു പ്രേതമായി.

ഇവിടെയാണ് ആധുനിക ജാവാസ്ക്രിപ്റ്റ്, അതിന്റെ ECMAScript 2021 (ES12) സവിശേഷതകളോടെ, ശക്തമായ ഒരു പരിഹാരം നൽകുന്നത്. WeakRef, FinalizationRegistry എന്നിവ ഉപയോഗിക്കുന്നതിലൂടെ, സാധാരണമായ ഈ ലീക്കുകൾ തടഞ്ഞ്, സ്വയം വൃത്തിയാക്കുന്ന ഒരു മെമ്മറി-അവയർ ഒബ്സെർവർ പാറ്റേൺ നമുക്ക് നിർമ്മിക്കാൻ കഴിയും. ഈ ലേഖനം ഈ നൂതന സാങ്കേതികതയെക്കുറിച്ചുള്ള ഒരു ആഴത്തിലുള്ള പഠനമാണ്. നമ്മൾ പ്രശ്നം പരിശോധിക്കുകയും, ടൂളുകൾ മനസ്സിലാക്കുകയും, ആദ്യം മുതൽ ശക്തമായ ഒരു നടപ്പാക്കൽ നിർമ്മിക്കുകയും, നിങ്ങളുടെ ഗ്ലോബൽ ആപ്ലിക്കേഷനുകളിൽ ഈ ശക്തമായ പാറ്റേൺ എപ്പോൾ, എവിടെ പ്രയോഗിക്കണമെന്ന് ചർച്ച ചെയ്യുകയും ചെയ്യും.

പ്രധാന പ്രശ്നം മനസ്സിലാക്കൽ: ക്ലാസിക് ഒബ്സെർവർ പാറ്റേണും അതിന്റെ മെമ്മറി ഉപയോഗവും

പരിഹാരം വിലയിരുത്തുന്നതിന് മുമ്പ്, നമ്മൾ പ്രശ്നം പൂർണ്ണമായി മനസ്സിലാക്കണം. പബ്ലിഷർ-സബ്സ്ക്രൈബർ പാറ്റേൺ എന്നും അറിയപ്പെടുന്ന ഒബ്സെർവർ പാറ്റേൺ, ഘടകങ്ങളെ പരസ്പരം വേർതിരിക്കാനാണ് രൂപകൽപ്പന ചെയ്തിരിക്കുന്നത്. ഒരു Subject (അല്ലെങ്കിൽ Publisher) അതിന്റെ ആശ്രിതരുടെ ഒരു ലിസ്റ്റ് സൂക്ഷിക്കുന്നു, ഇവരെ Observers (അല്ലെങ്കിൽ Subscribers) എന്ന് വിളിക്കുന്നു. Subject-ന്റെ സ്റ്റേറ്റ് മാറുമ്പോൾ, അത് അതിന്റെ എല്ലാ Observers-നെയും യാന്ത്രികമായി അറിയിക്കുന്നു, സാധാരണയായി അവരിൽ update() പോലുള്ള ഒരു പ്രത്യേക മെത്തേഡ് വിളിച്ചുകൊണ്ട്.

ജാവാസ്ക്രിപ്റ്റിൽ ഒരു ലളിതമായ, ക്ലാസിക് നടപ്പാക്കൽ നോക്കാം.

ഒരു ലളിതമായ Subject നടപ്പാക്കൽ

ഇവിടെ ഒരു അടിസ്ഥാന Subject ക്ലാസ് ഉണ്ട്. ഇതിന് ഒബ്സെർവർമാരെ സബ്സ്ക്രൈബ് ചെയ്യാനും, അൺസബ്സ്ക്രൈബ് ചെയ്യാനും, അറിയിക്കാനുമുള്ള മെത്തേഡുകൾ ഉണ്ട്.

class ClassicSubject {

  constructor() {

    this.observers = [];

  }

 

  subscribe(observer) {

    this.observers.push(observer);

    console.log(`${observer.name} has subscribed.`);

  }

 

  unsubscribe(observer) {

    this.observers = this.observers.filter(obs => obs !== observer);

    console.log(`${observer.name} has unsubscribed.`);

  }

 

  notify(data) {

    console.log('Notifying observers...');

    this.observers.forEach(observer => observer.update(data));

  }

}

Subject-ലേക്ക് സബ്സ്ക്രൈബ് ചെയ്യാൻ കഴിയുന്ന ഒരു ലളിതമായ Observer ക്ലാസ് ഇതാ.

class Observer {

  constructor(name) {

    this.name = name;

  }

 

  update(data) {

    console.log(`${this.name} received data: ${data}`);

  }

}

മറഞ്ഞിരിക്കുന്ന അപകടം: നീണ്ടുനിൽക്കുന്ന റഫറൻസുകൾ

നമ്മുടെ ഒബ്സെർവർമാരുടെ ലൈഫ് സൈക്കിൾ ശ്രദ്ധാപൂർവ്വം കൈകാര്യം ചെയ്യുന്നിടത്തോളം കാലം ഈ നടപ്പാക്കൽ നന്നായി പ്രവർത്തിക്കും. എന്നാൽ അങ്ങനെയല്ലാത്തപ്പോഴാണ് പ്രശ്നം ഉടലെടുക്കുന്നത്. ഒരു വലിയ ആപ്ലിക്കേഷനിലെ ഒരു സാധാരണ സാഹചര്യം പരിഗണിക്കുക: ഒരു ദീർഘകാലം നിലനിൽക്കുന്ന ഗ്ലോബൽ ഡാറ്റാ സ്റ്റോറും (Subject) അതിന്റെ കുറച്ച് ഡാറ്റ പ്രദർശിപ്പിക്കുന്ന ഒരു താൽക്കാലിക UI ഘടകവും (Observer).

നമുക്ക് ഈ സാഹചര്യം അനുകരിക്കാം:

const dataStore = new ClassicSubject();

 

function manageUIComponent() {

  let chartComponent = new Observer('ChartComponent');

  dataStore.subscribe(chartComponent);

 

  // ഘടകം അതിന്റെ ജോലി ചെയ്യുന്നു...

 

  // ഇപ്പോൾ, ഉപയോക്താവ് മറ്റൊരിടത്തേക്ക് പോകുന്നു, ഘടകം ഇനി ആവശ്യമില്ല.

  // ഒരു ഡെവലപ്പർ ക്ലീനപ്പ് കോഡ് ചേർക്കാൻ മറന്നേക്കാം:

  // dataStore.unsubscribe(chartComponent);

 

  chartComponent = null; // നമ്മൾ ഘടകത്തിലേക്കുള്ള നമ്മുടെ റഫറൻസ് ഒഴിവാക്കുന്നു.

}

 

manageUIComponent();

 

// ആപ്ലിക്കേഷൻ ലൈഫ് സൈക്കിളിൽ പിന്നീട്...

dataStore.notify('New data available!');

`manageUIComponent` ഫംഗ്ഷനിൽ, നമ്മൾ ഒരു `chartComponent` ഉണ്ടാക്കുകയും അതിനെ നമ്മുടെ `dataStore`-ലേക്ക് സബ്സ്ക്രൈബ് ചെയ്യുകയും ചെയ്യുന്നു. പിന്നീട്, നമ്മൾ `chartComponent` `null` ആയി സജ്ജീകരിക്കുന്നു, ഇത് നമ്മൾ അത് ഉപയോഗിച്ച് കഴിഞ്ഞുവെന്ന് സൂചിപ്പിക്കുന്നു. ഈ ഒബ്ജക്റ്റിലേക്ക് കൂടുതൽ റഫറൻസുകൾ ഇല്ലെന്ന് ജാവാസ്ക്രിപ്റ്റ് ഗാർബേജ് കളക്ടർ (GC) കാണുകയും അതിന്റെ മെമ്മറി വീണ്ടെടുക്കുകയും ചെയ്യുമെന്ന് നമ്മൾ പ്രതീക്ഷിക്കുന്നു.

എന്നാൽ മറ്റൊരു റഫറൻസ് ഉണ്ട്! `dataStore.observers` അറേ ഇപ്പോഴും `chartComponent` ഒബ്ജക്റ്റിലേക്ക് നേരിട്ടുള്ള, ശക്തമായ റഫറൻസ് നിലനിർത്തുന്നു. ഈ ഒരൊറ്റ നീണ്ടുനിൽക്കുന്ന റഫറൻസ് കാരണം, ഗാർബേജ് കളക്ടർക്ക് മെമ്മറി വീണ്ടെടുക്കാൻ കഴിയില്ല. `chartComponent` ഒബ്ജക്റ്റും അത് കൈവശം വച്ചിരിക്കുന്ന ഏതൊരു വിഭവങ്ങളും `dataStore`-ന്റെ മുഴുവൻ ജീവിതകാലത്തും മെമ്മറിയിൽ നിലനിൽക്കും. ഇത് ആവർത്തിച്ച് സംഭവിക്കുകയാണെങ്കിൽ - ഉദാഹരണത്തിന്, ഓരോ തവണയും ഒരു ഉപയോക്താവ് ഒരു മോഡൽ വിൻഡോ തുറക്കുകയും അടയ്ക്കുകയും ചെയ്യുമ്പോൾ - ആപ്ലിക്കേഷന്റെ മെമ്മറി ഉപയോഗം അനന്തമായി വളരും. ഇതൊരു ക്ലാസിക് മെമ്മറി ലീക്കാണ്.

ഒരു പുതിയ പ്രതീക്ഷ: WeakRef, FinalizationRegistry എന്നിവ പരിചയപ്പെടുത്തുന്നു

ഇത്തരം മെമ്മറി മാനേജ്മെന്റ് വെല്ലുവിളികൾ കൈകാര്യം ചെയ്യുന്നതിനായി ECMAScript 2021 രണ്ട് പുതിയ സവിശേഷതകൾ അവതരിപ്പിച്ചു: `WeakRef`, `FinalizationRegistry`. അവ വികസിത ടൂളുകളാണ്, ശ്രദ്ധയോടെ ഉപയോഗിക്കണം, എന്നാൽ നമ്മുടെ ഒബ്സെർവർ പാറ്റേൺ പ്രശ്നത്തിന് അവ തികഞ്ഞ പരിഹാരമാണ്.

എന്താണ് ഒരു WeakRef?

ഒരു `WeakRef` ഒബ്ജക്റ്റ് മറ്റൊരു ഒബ്ജക്റ്റിലേക്ക്, അതിന്റെ ടാർഗെറ്റ് എന്ന് വിളിക്കപ്പെടുന്ന, ഒരു വീക്ക് റഫറൻസ് സൂക്ഷിക്കുന്നു. ഒരു വീക്ക് റഫറൻസും സാധാരണ (ശക്തമായ) റഫറൻസും തമ്മിലുള്ള പ്രധാന വ്യത്യാസം ഇതാണ്: ഒരു വീക്ക് റഫറൻസ് അതിന്റെ ടാർഗെറ്റ് ഒബ്ജക്റ്റിനെ ഗാർബേജ് കളക്ട് ചെയ്യുന്നതിൽ നിന്ന് തടയുന്നില്ല.

ഒരു ഒബ്ജക്റ്റിലേക്കുള്ള റഫറൻസുകൾ വീക്ക് റഫറൻസുകൾ മാത്രമാണെങ്കിൽ, ജാവാസ്ക്രിപ്റ്റ് എഞ്ചിന് ആ ഒബ്ജക്റ്റ് നശിപ്പിക്കാനും അതിന്റെ മെമ്മറി വീണ്ടെടുക്കാനും സ്വാതന്ത്ര്യമുണ്ട്. നമ്മുടെ ഒബ്സെർവർ പ്രശ്നം പരിഹരിക്കാൻ നമുക്ക് കൃത്യമായി ഇതാണ് വേണ്ടത്.

ഒരു `WeakRef` ഉപയോഗിക്കാൻ, നിങ്ങൾ അതിന്റെ ഒരു ഇൻസ്റ്റൻസ് ഉണ്ടാക്കുക, ടാർഗെറ്റ് ഒബ്ജക്റ്റ് കൺസ്ട്രക്റ്ററിലേക്ക് നൽകുക. പിന്നീട് ടാർഗെറ്റ് ഒബ്ജക്റ്റ് ആക്സസ് ചെയ്യാൻ, നിങ്ങൾ `deref()` മെത്തേഡ് ഉപയോഗിക്കുക.

let targetObject = { id: 42 };

const weakRefToObject = new WeakRef(targetObject);

 

// ഒബ്ജക്റ്റ് ആക്സസ് ചെയ്യാൻ:

const retrievedObject = weakRefToObject.deref();

 

if (retrievedObject) {

  console.log(`Object is still alive: ${retrievedObject.id}`); // ഔട്ട്പുട്ട്: Object is still alive: 42

} else {

  console.log('Object has been garbage collected.');

}

`deref()` `undefined` തിരികെ നൽകാൻ സാധ്യതയുണ്ടെന്നതാണ് നിർണായകമായ കാര്യം. `targetObject`-ലേക്ക് ശക്തമായ റഫറൻസുകൾ ഒന്നും നിലവിലില്ലാത്തതിനാൽ അത് ഗാർബേജ് കളക്ട് ചെയ്യപ്പെടുമ്പോഴാണ് ഇത് സംഭവിക്കുന്നത്. ഈ സ്വഭാവമാണ് നമ്മുടെ മെമ്മറി-അവയർ ഒബ്സെർവർ പാറ്റേണിന്റെ അടിസ്ഥാനം.

എന്താണ് FinalizationRegistry?

ഒരു ഒബ്ജക്റ്റ് കളക്ട് ചെയ്യാൻ `WeakRef` അനുവദിക്കുന്നുണ്ടെങ്കിലും, അത് എപ്പോൾ കളക്ട് ചെയ്യപ്പെട്ടുവെന്ന് അറിയാൻ ഒരു വ്യക്തമായ വഴി നൽകുന്നില്ല. നമുക്ക് ഇടയ്ക്കിടെ `deref()` പരിശോധിച്ച് നമ്മുടെ ഒബ്സെർവർ ലിസ്റ്റിൽ നിന്ന് `undefined` ഫലങ്ങൾ നീക്കം ചെയ്യാൻ കഴിയും, പക്ഷേ അത് കാര്യക്ഷമമല്ല. ഇവിടെയാണ് `FinalizationRegistry` വരുന്നത്.

ഒരു രജിസ്റ്റർ ചെയ്ത ഒബ്ജക്റ്റ് ഗാർബേജ് കളക്ട് ചെയ്യപ്പെട്ടതിന് ശേഷം വിളിക്കപ്പെടുന്ന ഒരു കോൾബാക്ക് ഫംഗ്ഷൻ രജിസ്റ്റർ ചെയ്യാൻ ഒരു `FinalizationRegistry` നിങ്ങളെ അനുവദിക്കുന്നു. ഇത് മരണാനന്തര ശുചീകരണത്തിനുള്ള ഒരു സംവിധാനമാണ്.

ഇത് എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് ഇതാ:

1. നിങ്ങൾ ഒരു ക്ലീനപ്പ് കോൾബാക്ക് ഉപയോഗിച്ച് ഒരു രജിസ്ട്രി ഉണ്ടാക്കുന്നു.
2. നിങ്ങൾ ഒരു ഒബ്ജക്റ്റ് രജിസ്ട്രിയിൽ `register()` ചെയ്യുന്നു. നിങ്ങൾക്ക് ഒരു `heldValue` നൽകാനും കഴിയും, ഇത് ഒബ്ജക്റ്റ് കളക്ട് ചെയ്യപ്പെടുമ്പോൾ നിങ്ങളുടെ കോൾബാക്കിലേക്ക് കൈമാറുന്ന ഒരു ഡാറ്റയാണ്. ഈ `heldValue` ഒബ്ജക്റ്റിലേക്കുള്ള നേരിട്ടുള്ള റഫറൻസ് ആകരുത്, കാരണം അത് ഉദ്ദേശ്യത്തെ പരാജയപ്പെടുത്തും!

// 1. ക്ലീനപ്പ് കോൾബാക്ക് ഉപയോഗിച്ച് രജിസ്ട്രി ഉണ്ടാക്കുക

const registry = new FinalizationRegistry(heldValue => {

  console.log(`An object has been garbage collected. Cleanup token: ${heldValue}`);

});

 

(function() {

  let objectToTrack = { name: 'Temporary Data' };

  let cleanupToken = 'temp-data-123';

 

  // 2. ഒബ്ജക്റ്റ് രജിസ്റ്റർ ചെയ്യുകയും ക്ലീനപ്പിനായി ഒരു ടോക്കൺ നൽകുകയും ചെയ്യുക

  registry.register(objectToTrack, cleanupToken);

 

  // objectToTrack ഇവിടെ സ്കോപ്പിന് പുറത്തുപോകുന്നു

})();

 

// ഭാവിയിൽ എപ്പോഴെങ്കിലും, GC പ്രവർത്തിച്ചതിന് ശേഷം, കൺസോൾ ലോഗ് ചെയ്യും:

// "An object has been garbage collected. Cleanup token: temp-data-123"

പ്രധാന മുന്നറിയിപ്പുകളും മികച്ച രീതികളും

നടപ്പാക്കലിലേക്ക് കടക്കുന്നതിന് മുമ്പ്, ഈ ടൂളുകളുടെ സ്വഭാവം മനസ്സിലാക്കേണ്ടത് അത്യാവശ്യമാണ്. ഗാർബേജ് കളക്ടറിന്റെ പെരുമാറ്റം വളരെ അധികം നടപ്പാക്കലിനെ ആശ്രയിച്ചിരിക്കുന്നു, അത് മുൻകൂട്ടി പ്രവചിക്കാൻ കഴിയാത്തതുമാണ്. ഇതിനർത്ഥം:

• ഒരു ഒബ്ജക്റ്റ് എപ്പോൾ കളക്ട് ചെയ്യപ്പെടുമെന്ന് നിങ്ങൾക്ക് പ്രവചിക്കാൻ കഴിയില്ല. അത് എത്തിച്ചേരാൻ കഴിയാതായതിന് ശേഷം സെക്കൻഡുകളോ, മിനിറ്റുകളോ, അതിൽ കൂടുതലോ എടുത്തേക്കാം.
• `FinalizationRegistry` കോൾബാക്കുകൾ കൃത്യസമയത്ത് അല്ലെങ്കിൽ പ്രവചനാതീതമായ രീതിയിൽ പ്രവർത്തിക്കുമെന്ന് നിങ്ങൾക്ക് വിശ്വസിക്കാൻ കഴിയില്ല. അവ ക്ലീനപ്പിനുള്ളതാണ്, നിർണായക ആപ്ലിക്കേഷൻ ലോജിക്കിനല്ല.
• `WeakRef`, `FinalizationRegistry` എന്നിവയുടെ അമിതമായ ഉപയോഗം കോഡ് മനസ്സിലാക്കാൻ പ്രയാസമുള്ളതാക്കും. ഒബ്ജക്റ്റ് ലൈഫ് സൈക്കിളുകൾ വ്യക്തവും കൈകാര്യം ചെയ്യാൻ കഴിയുന്നതുമാണെങ്കിൽ എല്ലായ്പ്പോഴും ലളിതമായ പരിഹാരങ്ങൾക്ക് (വ്യക്തമായ `unsubscribe` കോളുകൾ പോലുള്ളവ) മുൻഗണന നൽകുക.

ഒരു ഒബ്ജക്റ്റിന്റെ (ഒബ്സെർവർ) ലൈഫ് സൈക്കിൾ മറ്റൊരു ഒബ്ജക്റ്റിൽ (സബ്ജക്ട്) നിന്ന് ശരിക്കും സ്വതന്ത്രവും അജ്ഞാതവുമാകുന്ന സാഹചര്യങ്ങൾക്ക് ഈ സവിശേഷതകൾ ഏറ്റവും അനുയോജ്യമാണ്.

`WeakRefObserver` പാറ്റേൺ നിർമ്മിക്കൽ: ഒരു ഘട്ടം ഘട്ടമായുള്ള നടപ്പാക്കൽ

ഇനി, മെമ്മറി-സുരക്ഷിതമായ ഒരു `WeakRefSubject` ക്ലാസ് നിർമ്മിക്കുന്നതിനായി നമുക്ക് `WeakRef`, `FinalizationRegistry` എന്നിവ സംയോജിപ്പിക്കാം.

ഘട്ടം 1: `WeakRefSubject` ക്ലാസ് ഘടന

നമ്മുടെ പുതിയ ക്ലാസ് നേരിട്ടുള്ള റഫറൻസുകൾക്ക് പകരം ഒബ്സെർവർമാരിലേക്ക് `WeakRef`-കൾ സംഭരിക്കും. ഒബ്സെർവർമാരുടെ ലിസ്റ്റ് യാന്ത്രികമായി വൃത്തിയാക്കുന്നതിന് ഒരു `FinalizationRegistry`-യും ഇതിലുണ്ടാകും.

class WeakRefSubject {

  constructor() {

    this.observers = new Set(); // എളുപ്പത്തിൽ നീക്കം ചെയ്യുന്നതിനായി Set ഉപയോഗിക്കുന്നു

 

    // ഫൈനലൈസർ കോൾബാക്ക്. രജിസ്ട്രേഷൻ സമയത്ത് നമ്മൾ നൽകുന്ന ഹെൽഡ് വാല്യൂ ഇത് സ്വീകരിക്കുന്നു.

    // നമ്മുടെ കാര്യത്തിൽ, ഹെൽഡ് വാല്യൂ WeakRef ഇൻസ്റ്റൻസ് തന്നെയായിരിക്കും.

    this.cleanupRegistry = new FinalizationRegistry(weakRefObserver => {

      console.log('Finalizer: An observer has been garbage collected. Cleaning up...');

      this.observers.delete(weakRefObserver);

    });

  }

}

നമ്മുടെ ഒബ്സെർവർ ലിസ്റ്റിനായി നമ്മൾ ഒരു `Array`-ക്ക് പകരം ഒരു `Set` ആണ് ഉപയോഗിക്കുന്നത്. കാരണം, ഒരു `Set`-ൽ നിന്ന് ഒരു ഇനം ഡിലീറ്റ് ചെയ്യുന്നത് ഒരു `Array` ഫിൽട്ടർ ചെയ്യുന്നതിനേക്കാൾ (O(n)) വളരെ കാര്യക്ഷമമാണ് (O(1) ശരാശരി സമയ സങ്കീർണ്ണത), ഇത് നമ്മുടെ ക്ലീനപ്പ് ലോജിക്കിൽ ഉപയോഗപ്രദമാകും.

ഘട്ടം 2: `subscribe` മെത്തേഡ്

`subscribe` മെത്തേഡിലാണ് മാന്ത്രികത ആരംഭിക്കുന്നത്. ഒരു ഒബ്സെർവർ സബ്സ്ക്രൈബ് ചെയ്യുമ്പോൾ, നമ്മൾ:

1. ഒബ്സെർവറിലേക്ക് പോയിന്റ് ചെയ്യുന്ന ഒരു `WeakRef` ഉണ്ടാക്കും.
2. ഈ `WeakRef` നമ്മുടെ `observers` സെറ്റിലേക്ക് ചേർക്കും.
3. പുതുതായി ഉണ്ടാക്കിയ `WeakRef`-നെ `heldValue` ആയി ഉപയോഗിച്ച്, യഥാർത്ഥ ഒബ്സെർവർ ഒബ്ജക്റ്റിനെ നമ്മുടെ `FinalizationRegistry`-ൽ രജിസ്റ്റർ ചെയ്യും.

// WeakRefSubject ക്ലാസിനുള്ളിൽ...

subscribe(observer) {

  // ഈ റഫറൻസുള്ള ഒരു ഒബ്സെർവർ ഇതിനകം നിലവിലുണ്ടോയെന്ന് പരിശോധിക്കുക

  for (const ref of this.observers) {

    if (ref.deref() === observer) {

      console.warn('Observer already subscribed.');

      return;

    }

  }

 

  const weakRefObserver = new WeakRef(observer);

  this.observers.add(weakRefObserver);

 

  // യഥാർത്ഥ ഒബ്സെർവർ ഒബ്ജക്റ്റ് രജിസ്റ്റർ ചെയ്യുക. അത് കളക്ട് ചെയ്യപ്പെടുമ്പോൾ,

  // ഫൈനലൈസർ `weakRefObserver` ആർഗ്യുമെന്റായി വിളിപ്പിക്കും.

  this.cleanupRegistry.register(observer, weakRefObserver);

 

  console.log('An observer has subscribed.');

}

ഈ സജ്ജീകരണം ഒരു സമർത്ഥമായ ലൂപ്പ് ഉണ്ടാക്കുന്നു: സബ്ജക്ട് ഒബ്സെർവറിലേക്ക് ഒരു വീക്ക് റഫറൻസ് സൂക്ഷിക്കുന്നു. രജിസ്ട്രി ഒബ്സെർവറിലേക്ക് (ആന്തരികമായി) ഒരു ശക്തമായ റഫറൻസ് സൂക്ഷിക്കുന്നു, അത് ഗാർബേജ് കളക്ട് ചെയ്യപ്പെടുന്നത് വരെ. കളക്ട് ചെയ്തുകഴിഞ്ഞാൽ, രജിസ്ട്രിയുടെ കോൾബാക്ക് വീക്ക് റഫറൻസ് ഇൻസ്റ്റൻസ് ഉപയോഗിച്ച് ട്രിഗർ ചെയ്യപ്പെടുന്നു, അത് നമുക്ക് നമ്മുടെ `observers` സെറ്റ് വൃത്തിയാക്കാൻ ഉപയോഗിക്കാം.

ഘട്ടം 3: `unsubscribe` മെത്തേഡ്

യാന്ത്രിക ക്ലീനപ്പ് ഉണ്ടെങ്കിലും, കൃത്യമായ നീക്കം ചെയ്യൽ ആവശ്യമുള്ള സാഹചര്യങ്ങൾക്കായി നമ്മൾ ഒരു മാനുവൽ `unsubscribe` മെത്തേഡ് നൽകണം. ഈ മെത്തേഡിന് നമ്മുടെ സെറ്റിലെ ഓരോ `WeakRef`-നെയും ഡീറഫറൻസ് ചെയ്ത് നമ്മൾ നീക്കം ചെയ്യാൻ ആഗ്രഹിക്കുന്ന ഒബ്സെർവറുമായി താരതമ്യം ചെയ്ത് ശരിയായ `WeakRef` കണ്ടെത്തേണ്ടതുണ്ട്.

// WeakRefSubject ക്ലാസിനുള്ളിൽ...

unsubscribe(observer) {

  let refToRemove = null;

  for (const weakRef of this.observers) {

    if (weakRef.deref() === observer) {

      refToRemove = weakRef;

      break;

    }

  }

 

  if (refToRemove) {

    this.observers.delete(refToRemove);

    // പ്രധാനം: നമ്മൾ ഫൈനലൈസറിൽ നിന്നും അൺരജിസ്റ്റർ ചെയ്യണം

    // പിന്നീട് കോൾബാക്ക് അനാവശ്യമായി പ്രവർത്തിക്കുന്നത് തടയാൻ.

    this.cleanupRegistry.unregister(observer);

    console.log('An observer has unsubscribed manually.');

  }

}

ഘട്ടം 4: `notify` മെത്തേഡ്

`notify` മെത്തേഡ് നമ്മുടെ `WeakRef`-കളുടെ സെറ്റിലൂടെ സഞ്ചരിക്കുന്നു. ഓരോന്നിനും, അത് യഥാർത്ഥ ഒബ്സെർവർ ഒബ്ജക്റ്റ് ലഭിക്കാൻ `deref()` ചെയ്യാൻ ശ്രമിക്കുന്നു. `deref()` വിജയിക്കുകയാണെങ്കിൽ, അതിനർത്ഥം ഒബ്സെർവർ ഇപ്പോഴും ജീവനോടെയുണ്ടെന്നാണ്, നമുക്ക് അതിന്റെ `update` മെത്തേഡ് വിളിക്കാം. അത് `undefined` നൽകുകയാണെങ്കിൽ, ഒബ്സെർവർ കളക്ട് ചെയ്യപ്പെട്ടു, നമുക്ക് അതിനെ അവഗണിക്കാം. `FinalizationRegistry` ഒടുവിൽ അതിന്റെ `WeakRef`-നെ സെറ്റിൽ നിന്ന് നീക്കം ചെയ്യും.

// WeakRefSubject ക്ലാസിനുള്ളിൽ...

notify(data) {

  console.log('Notifying observers...');

  for (const weakRefObserver of this.observers) {

    const observer = weakRefObserver.deref();

    if (observer) {

      // ഒബ്സെർവർ ഇപ്പോഴും ജീവനോടെയുണ്ട്

      observer.update(data);

    } else {

      // ഒബ്സെർവർ ഗാർബേജ് കളക്ട് ചെയ്യപ്പെട്ടു.

      // FinalizationRegistry ഈ weakRef-നെ സെറ്റിൽ നിന്ന് നീക്കം ചെയ്യുന്നത് കൈകാര്യം ചെയ്യും.

      console.log('Found a dead observer reference during notification.');

    }

  }

}

എല്ലാം ഒരുമിച്ച് ചേർക്കുന്നു: ഒരു പ്രായോഗിക ഉദാഹരണം

നമ്മുടെ UI ഘടകത്തിന്റെ സാഹചര്യത്തിലേക്ക് വീണ്ടും വരാം, എന്നാൽ ഇത്തവണ നമ്മുടെ പുതിയ `WeakRefSubject` ഉപയോഗിക്കാം. എളുപ്പത്തിനായി നമ്മൾ മുമ്പത്തെ അതേ `Observer` ക്ലാസ് ഉപയോഗിക്കും.

// അതേ ലളിതമായ Observer ക്ലാസ്

class Observer {

  constructor(name) {

    this.name = name;

  }

  update(data) {

    console.log(`${this.name} received data: ${data}`);

  }

}

ഇനി, നമുക്ക് ഒരു ഗ്ലോബൽ ഡാറ്റാ സർവീസ് ഉണ്ടാക്കി ഒരു താൽക്കാലിക UI വിഡ്ജറ്റ് അനുകരിക്കാം.

const globalDataService = new WeakRefSubject();

function createAndDestroyWidget() {

  console.log('--- Creating and subscribing new widget ---');

  let chartWidget = new Observer('RealTimeChartWidget');

  globalDataService.subscribe(chartWidget);

 

  // വിഡ്ജറ്റ് ഇപ്പോൾ സജീവമാണ്, അറിയിപ്പുകൾ സ്വീകരിക്കും

  globalDataService.notify({ price: 100 });

 

  console.log('--- Destroying widget (releasing our reference) ---');

  // നമ്മൾ വിഡ്ജറ്റ് ഉപയോഗിച്ച് കഴിഞ്ഞു. നമ്മുടെ റഫറൻസ് null ആയി സജ്ജീകരിക്കുന്നു.

  // unsubscribe() വിളിക്കേണ്ട ആവശ്യമില്ല.

  chartWidget = null;

}

createAndDestroyWidget();

console.log('--- After widget destruction, before garbage collection ---');

globalDataService.notify({ price: 105 });

`createAndDestroyWidget()` പ്രവർത്തിപ്പിച്ച ശേഷം, `chartWidget` ഒബ്ജക്റ്റിനെ ഇപ്പോൾ നമ്മുടെ `globalDataService`-നുള്ളിലെ `WeakRef` മാത്രമാണ് റഫർ ചെയ്യുന്നത്. ഇതൊരു വീക്ക് റഫറൻസായതിനാൽ, ഒബ്ജക്റ്റ് ഇപ്പോൾ ഗാർബേജ് കളക്ഷന് യോഗ്യമാണ്.

ഗാർബേജ് കളക്ടർ ഒടുവിൽ പ്രവർത്തിക്കുമ്പോൾ (അത് നമുക്ക് പ്രവചിക്കാൻ കഴിയില്ല), രണ്ട് കാര്യങ്ങൾ സംഭവിക്കും:

1. `chartWidget` ഒബ്ജക്റ്റ് മെമ്മറിയിൽ നിന്ന് നീക്കം ചെയ്യപ്പെടും.
2. നമ്മുടെ `FinalizationRegistry`-യുടെ കോൾബാക്ക് ട്രിഗർ ചെയ്യപ്പെടും, അത് ഇപ്പോൾ പ്രവർത്തനരഹിതമായ `WeakRef`-നെ `globalDataService.observers` സെറ്റിൽ നിന്ന് നീക്കം ചെയ്യും.

ഗാർബേജ് കളക്ടർ പ്രവർത്തിച്ചതിന് ശേഷം നമ്മൾ വീണ്ടും `notify` വിളിക്കുകയാണെങ്കിൽ, `deref()` കോൾ `undefined` നൽകും, പ്രവർത്തനരഹിതമായ ഒബ്സെർവറിനെ ഒഴിവാക്കും, ആപ്ലിക്കേഷൻ മെമ്മറി ലീക്കുകളില്ലാതെ കാര്യക്ഷമമായി പ്രവർത്തിക്കുന്നത് തുടരും. നമ്മൾ ഒബ്സെർവറിന്റെ ലൈഫ് സൈക്കിളിനെ സബ്ജക്റ്റിൽ നിന്ന് വിജയകരമായി വേർപെടുത്തി.

`WeakRefObserver` പാറ്റേൺ എപ്പോൾ ഉപയോഗിക്കണം (എപ്പോൾ ഒഴിവാക്കണം)

ഈ പാറ്റേൺ ശക്തമാണ്, പക്ഷേ ഇതൊരു ഒറ്റമൂലിയല്ല. ഇത് സങ്കീർണ്ണത കൊണ്ടുവരികയും പ്രവചിക്കാൻ കഴിയാത്ത പെരുമാറ്റത്തെ ആശ്രയിക്കുകയും ചെയ്യുന്നു. ഇത് ജോലിക്കുള്ള ശരിയായ ടൂൾ എപ്പോഴാണെന്ന് അറിയേണ്ടത് നിർണായകമാണ്.

അനുയോജ്യമായ ഉപയോഗ സാഹചര്യങ്ങൾ

• ദീർഘകാലം നിലനിൽക്കുന്ന സബ്ജക്റ്റുകളും ഹ്രസ്വകാല ഒബ്സെർവർമാരും: ഇതാണ് ഏറ്റവും പ്രധാനപ്പെട്ട ഉപയോഗ സാഹചര്യം. ഒരു ഗ്ലോബൽ സർവീസ്, ഡാറ്റാ സ്റ്റോർ, അല്ലെങ്കിൽ കാഷെ (സബ്ജക്ട്) ആപ്ലിക്കേഷന്റെ മുഴുവൻ ജീവിതകാലത്തും നിലനിൽക്കുന്നു, അതേസമയം നിരവധി UI ഘടകങ്ങൾ, താൽക്കാലിക വർക്കറുകൾ, അല്ലെങ്കിൽ പ്ലഗിനുകൾ (ഒബ്സെർവർമാർ) അടിക്കടി ഉണ്ടാക്കുകയും നശിപ്പിക്കുകയും ചെയ്യുന്നു.
• കാഷിംഗ് സംവിധാനങ്ങൾ: ഒരു സങ്കീർണ്ണ ഒബ്ജക്റ്റിനെ ഏതെങ്കിലും കണക്കുകൂട്ടിയ ഫലത്തിലേക്ക് മാപ്പ് ചെയ്യുന്ന ഒരു കാഷെ സങ്കൽപ്പിക്കുക. നിങ്ങൾക്ക് കീ ഒബ്ജക്റ്റിനായി ഒരു `WeakRef` ഉപയോഗിക്കാം. ആപ്ലിക്കേഷന്റെ മറ്റ് ഭാഗങ്ങളിൽ നിന്ന് യഥാർത്ഥ ഒബ്ജക്റ്റ് ഗാർബേജ് കളക്ട് ചെയ്യപ്പെട്ടാൽ, `FinalizationRegistry`-ക്ക് നിങ്ങളുടെ കാഷെയിലെ അനുബന്ധ എൻട്രി യാന്ത്രികമായി വൃത്തിയാക്കാൻ കഴിയും, ഇത് മെമ്മറി വീക്കം തടയുന്നു.
• പ്ലഗിൻ, എക്സ്റ്റൻഷൻ ആർക്കിടെക്ചറുകൾ: നിങ്ങൾ മൂന്നാം കക്ഷി മൊഡ്യൂളുകളെ ഇവന്റുകളിലേക്ക് സബ്സ്ക്രൈബ് ചെയ്യാൻ അനുവദിക്കുന്ന ഒരു കോർ സിസ്റ്റം നിർമ്മിക്കുകയാണെങ്കിൽ, ഒരു `WeakRefObserver` ഉപയോഗിക്കുന്നത് ഒരു സുരക്ഷാതലം നൽകുന്നു. അൺസബ്സ്ക്രൈബ് ചെയ്യാൻ മറക്കുന്ന ഒരു മോശമായി എഴുതിയ പ്ലഗിൻ നിങ്ങളുടെ കോർ ആപ്ലിക്കേഷനിൽ മെമ്മറി ലീക്ക് ഉണ്ടാക്കുന്നത് ഇത് തടയുന്നു.
• ഡാറ്റയെ DOM എലമെന്റുകളുമായി മാപ്പ് ചെയ്യൽ: ഒരു ഡിക്ലറേറ്റീവ് ഫ്രെയിംവർക്ക് ഇല്ലാത്ത സാഹചര്യങ്ങളിൽ, നിങ്ങൾക്ക് ചില ഡാറ്റയെ ഒരു DOM എലമെന്റുമായി ബന്ധപ്പെടുത്താൻ താൽപ്പര്യമുണ്ടാകാം. നിങ്ങൾ ഇത് DOM എലമെന്റ് കീ ആയി ഒരു മാപ്പിൽ സൂക്ഷിക്കുകയാണെങ്കിൽ, എലമെന്റ് DOM-ൽ നിന്ന് നീക്കം ചെയ്യപ്പെട്ടാലും നിങ്ങളുടെ മാപ്പിൽ ഇപ്പോഴും ഉണ്ടെങ്കിൽ ഒരു മെമ്മറി ലീക്ക് ഉണ്ടാകാം. `WeakMap` ഇവിടെ ഒരു മികച്ച തിരഞ്ഞെടുപ്പാണ്, പക്ഷേ തത്വം ഒന്നുതന്നെയാണ്: ഡാറ്റയുടെ ലൈഫ് സൈക്കിൾ എലമെന്റിന്റെ ലൈഫ് സൈക്കിളുമായി ബന്ധപ്പെട്ടിരിക്കണം, തിരിച്ചല്ല.

ക്ലാസിക് ഒബ്സെർവറിൽ എപ്പോൾ ഉറച്ചുനിൽക്കണം

• ദൃഢമായി ബന്ധിപ്പിച്ച ലൈഫ് സൈക്കിളുകൾ: സബ്ജക്റ്റും അതിന്റെ ഒബ്സെർവർമാരും എപ്പോഴും ഒരുമിച്ച് അല്ലെങ്കിൽ ഒരേ സ്കോപ്പിൽ ഉണ്ടാക്കുകയും നശിപ്പിക്കുകയും ചെയ്യുകയാണെങ്കിൽ, `WeakRef`-ന്റെ അധികഭാരവും സങ്കീർണ്ണതയും അനാവശ്യമാണ്. ഒരു ലളിതമായ, വ്യക്തമായ `unsubscribe()` കോൾ കൂടുതൽ വായിക്കാവുന്നതും പ്രവചിക്കാവുന്നതുമാണ്.
• പ്രകടനത്തിന് നിർണായകമായ ഹോട്ട് പാത്തുകൾ: `deref()` മെത്തേഡിന് ചെറുതാണെങ്കിലും പൂജ്യമല്ലാത്ത പ്രകടനച്ചെലവുണ്ട്. നിങ്ങൾ ആയിരക്കണക്കിന് ഒബ്സെർവർമാരെ സെക്കൻഡിൽ നൂറുകണക്കിന് തവണ അറിയിക്കുകയാണെങ്കിൽ (ഉദാഹരണത്തിന്, ഒരു ഗെയിം ലൂപ്പിലോ ഹൈ-ഫ്രീക്വൻസി ഡാറ്റാ വിഷ്വലൈസേഷനിലോ), നേരിട്ടുള്ള റഫറൻസുകളുള്ള ക്ലാസിക് നടപ്പാക്കൽ വേഗതയേറിയതായിരിക്കും.
• ലളിതമായ ആപ്ലിക്കേഷനുകളും സ്ക്രിപ്റ്റുകളും: ചെറിയ ആപ്ലിക്കേഷനുകൾക്കോ സ്ക്രിപ്റ്റുകൾക്കോ വേണ്ടി, ആപ്ലിക്കേഷൻ ജീവിതകാലം കുറവും മെമ്മറി മാനേജ്മെന്റ് ഒരു പ്രധാന ആശങ്കയുമല്ലാത്തയിടത്ത്, ക്ലാസിക് പാറ്റേൺ നടപ്പാക്കാനും മനസ്സിലാക്കാനും ലളിതമാണ്. ആവശ്യമില്ലാത്തയിടത്ത് സങ്കീർണ്ണത ചേർക്കരുത്.
• കൃത്യമായ ക്ലീനപ്പ് ആവശ്യമുള്ളപ്പോൾ: ഒരു ഒബ്സെർവർ വേർപെടുത്തുന്ന കൃത്യമായ നിമിഷത്തിൽ നിങ്ങൾക്ക് ഒരു പ്രവർത്തനം നടത്തണമെങ്കിൽ (ഉദാഹരണത്തിന്, ഒരു കൗണ്ടർ അപ്ഡേറ്റ് ചെയ്യുക, ഒരു പ്രത്യേക ഹാർഡ്‌വെയർ റിസോഴ്സ് റിലീസ് ചെയ്യുക), നിങ്ങൾ ഒരു മാനുവൽ `unsubscribe()` മെത്തേഡ് ഉപയോഗിക്കണം. `FinalizationRegistry`-യുടെ പ്രവചിക്കാൻ കഴിയാത്ത സ്വഭാവം പ്രവചനാതീതമായി നടപ്പിലാക്കേണ്ട ലോജിക്കിന് അനുയോജ്യമല്ലാതാക്കുന്നു.

സോഫ്റ്റ്‌വെയർ ആർക്കിടെക്ചറിനുള്ള വിശാലമായ പ്രത്യാഘാതങ്ങൾ

ജാവാസ്ക്രിപ്റ്റ് പോലുള്ള ഒരു ഉയർന്ന തലത്തിലുള്ള ഭാഷയിലേക്ക് വീക്ക് റഫറൻസുകൾ അവതരിപ്പിക്കുന്നത് പ്ലാറ്റ്‌ഫോമിന്റെ പക്വതയെ സൂചിപ്പിക്കുന്നു. ഇത് ഡെവലപ്പർമാരെ കൂടുതൽ സങ്കീർണ്ണവും പ്രതിരോധശേഷിയുള്ളതുമായ സിസ്റ്റങ്ങൾ നിർമ്മിക്കാൻ അനുവദിക്കുന്നു, പ്രത്യേകിച്ച് ദീർഘനേരം പ്രവർത്തിക്കുന്ന ആപ്ലിക്കേഷനുകൾക്ക്. ഈ പാറ്റേൺ വാസ്തുവിദ്യാപരമായ ചിന്തയിൽ ഒരു മാറ്റം പ്രോത്സാഹിപ്പിക്കുന്നു:

• യഥാർത്ഥ വേർപെടുത്തൽ: ഇത് കേവലം ഇന്റർഫേസിനപ്പുറം ഒരു വേർപെടുത്തൽ സാധ്യമാക്കുന്നു. നമുക്ക് ഇപ്പോൾ ഘടകങ്ങളുടെ ലൈഫ് സൈക്കിളുകൾ തന്നെ വേർപെടുത്താൻ കഴിയും. അതിന്റെ ഒബ്സെർവർമാർ എപ്പോൾ ഉണ്ടാക്കപ്പെടുന്നുവെന്നോ നശിപ്പിക്കപ്പെടുന്നുവെന്നോ സബ്ജക്റ്റിന് ഒന്നും അറിയേണ്ടതില്ല.
• രൂപകൽപ്പനയിലൂടെയുള്ള പ്രതിരോധശേഷി: പ്രോഗ്രാമർ പിശകുകൾക്ക് കൂടുതൽ പ്രതിരോധശേഷിയുള്ള സിസ്റ്റങ്ങൾ നിർമ്മിക്കാൻ ഇത് സഹായിക്കുന്നു. മറന്നുപോയ ഒരു `unsubscribe()` കോൾ കണ്ടെത്താൻ പ്രയാസമുള്ള ഒരു സാധാരണ ബഗ് ആണ്. ഈ പാറ്റേൺ ആ വിഭാഗത്തിലുള്ള പിശകുകളെ ലഘൂകരിക്കുന്നു.
• ഫ്രെയിംവർക്ക്, ലൈബ്രറി രചയിതാക്കളെ പ്രാപ്തരാക്കൽ: മറ്റ് ഡെവലപ്പർമാർക്കായി ഫ്രെയിംവർക്കുകൾ, ലൈബ്രറികൾ, അല്ലെങ്കിൽ പ്ലാറ്റ്‌ഫോമുകൾ നിർമ്മിക്കുന്നവർക്ക്, ഈ ടൂളുകൾ അമൂല്യമാണ്. ലൈബ്രറി ഉപഭോക്താക്കളുടെ ദുരുപയോഗത്തിന് സാധ്യത കുറഞ്ഞതും കൂടുതൽ സ്ഥിരതയുള്ള ആപ്ലിക്കേഷനുകളിലേക്ക് നയിക്കുന്നതുമായ ശക്തമായ API-കൾ ഉണ്ടാക്കാൻ അവ അനുവദിക്കുന്നു.

ഉപസംഹാരം: ആധുനിക ജാവാസ്ക്രിപ്റ്റ് ഡെവലപ്പർക്കുള്ള ഒരു ശക്തമായ ഉപകരണം

ക്ലാസിക് ഒബ്സെർവർ പാറ്റേൺ സോഫ്റ്റ്‌വെയർ ഡിസൈനിന്റെ ഒരു അടിസ്ഥാന ഘടകമാണ്, എന്നാൽ ശക്തമായ റഫറൻസുകളെ ആശ്രയിക്കുന്നത് ജാവാസ്ക്രിപ്റ്റ് ആപ്ലിക്കേഷനുകളിൽ സൂക്ഷ്മവും നിരാശാജനകവുമായ മെമ്മറി ലീക്കുകളുടെ ഒരു ഉറവിടമായി വളരെക്കാലമായി നിലനിൽക്കുന്നു. ES2021-ൽ `WeakRef`, `FinalizationRegistry` എന്നിവയുടെ വരവോടെ, ഈ പരിമിതി മറികടക്കാനുള്ള ടൂളുകൾ ഇപ്പോൾ നമ്മുടെ പക്കലുണ്ട്.

നീണ്ടുനിൽക്കുന്ന റഫറൻസുകളുടെ അടിസ്ഥാന പ്രശ്നം മനസ്സിലാക്കുന്നതിൽ നിന്ന്, പൂർണ്ണമായും മെമ്മറി-അവയർ ആയ ഒരു `WeakRefSubject` ആദ്യം മുതൽ നിർമ്മിക്കുന്നത് വരെ നമ്മൾ യാത്ര ചെയ്തു. 'നിരീക്ഷിക്കപ്പെടുമ്പോഴും' ഒബ്ജക്റ്റുകളെ ഗാർബേജ് കളക്ട് ചെയ്യാൻ `WeakRef` എങ്ങനെ അനുവദിക്കുന്നുവെന്നും, നമ്മുടെ ഒബ്സെർവർ ലിസ്റ്റ് വൃത്തിയായി സൂക്ഷിക്കാൻ `FinalizationRegistry` എങ്ങനെ യാന്ത്രിക ക്ലീനപ്പ് സംവിധാനം നൽകുന്നുവെന്നും നമ്മൾ കണ്ടു.

എന്നിരുന്നാലും, വലിയ ശക്തിയോടൊപ്പം വലിയ ഉത്തരവാദിത്തവും വരുന്നു. ഇവയുടെ പ്രവചനാതീതമായ സ്വഭാവത്തിന് ശ്രദ്ധാപൂർവമായ പരിഗണന ആവശ്യമുള്ള വികസിത സവിശേഷതകളാണ്. നല്ല ആപ്ലിക്കേഷൻ ഡിസൈനിനും ശ്രദ്ധാപൂർവമായ ലൈഫ് സൈക്കിൾ മാനേജ്മെന്റിനും പകരമാവില്ല ഇവ. എന്നാൽ ശരിയായ പ്രശ്നങ്ങൾക്ക് പ്രയോഗിക്കുമ്പോൾ - ദീർഘകാലം നിലനിൽക്കുന്ന സേവനങ്ങളും ഹ്രസ്വകാല ഘടകങ്ങളും തമ്മിലുള്ള ആശയവിനിമയം കൈകാര്യം ചെയ്യുന്നത് പോലുള്ളവ - WeakRef ഒബ്സെർവർ പാറ്റേൺ അസാധാരണമാംവിധം ശക്തമായ ഒരു സാങ്കേതികതയാണ്. ഇതിൽ വൈദഗ്ദ്ധ്യം നേടുന്നതിലൂടെ, ആധുനിക, ഡൈനാമിക് വെബിന്റെ ആവശ്യകതകൾ നിറവേറ്റാൻ തയ്യാറായ, കൂടുതൽ കരുത്തുറ്റതും കാര്യക്ഷമവും അളക്കാവുന്നതുമായ ജാവാസ്ക്രിപ്റ്റ് ആപ്ലിക്കേഷനുകൾ നിങ്ങൾക്ക് എഴുതാൻ കഴിയും.